1. Field of the Invention
The present invention relates generally to graphical user interface design and programming. More specifically, it relates to computer software for managing the construction of a GUI in a JAVA(trademark) programming environment.
2. Discussion of Related Art
Designing an efficient and ergonomic user interface is an integral stage of most application development projects. The graphical user interface (xe2x80x9cGUIxe2x80x9d) is what the user sees and interacts with. The GUI must present information and choices to a user in a way that is not only pleasing and natural to the eye but conducive to efficient use of the underlying application. Thus, designing an effective GUI can take significant time and resources, not only in the actual design of the GUI but in simply trying different configurations and layout, often xe2x80x9con the fly,xe2x80x9d and actually seeing what works on the screen.
However, most GUI layout managers are difficult to work with and have several drawbacks. None have the flexibility, robustness, and simplicity needed to easily layout visual components in a GUI in a pleasing and resizable arrangement with a minimum of developer effort. Some are flexible and give the GUI designer many options, but are difficult to use and require too much time from the designer. These include GridBagLayout Layout Manager and BorderLayout Layout Manager.
For example, although GridbagLayout is a powerful layout manager in Java(trademark) application programming, developers must create and specify a GridBagConstraints object before a component can be added to a container. The elements of a GridBagConstraints object are complex and not easily understood. Use of a GUI to specify a GridBagLayout easily is virtually impossible, forcing developers to hand code the placement of the components (e.g., buttons, text labels, etc). In other words, developers cannot xe2x80x9cdrag and dropxe2x80x9d components directly into the layout manager. BorderLayout is also flexible and allows components to be aligned at the center or north, south, east, and west sides of a container. However, it has no concept of placing components anywhere else, and requires nesting containers several layers deep to do certain tasks. BorderLayout can only respect one dimension of a preferred size of a component for the north, south, east, and west alignments; for center, the preferred size is completely ignored. In addition, both layout managers are difficult to understand for new users.
Other layout managers are simple to use but have limited abilities, such as FlowLayout and GridLayout. For example, FlowLayout adheres to a component""s natural preferred size and lays components out from left to right, one after another. However, components are not aligned in the vertical direction, and resizing the container can cause components to shift row or columns. With GridLayout, and another layout manager, BoxLayout, components are forced into cells having the same size.
In addition to the individual drawbacks of each of the layout managers, converting from one layout manager to another is difficult. The best that can be done presently is capturing the current size and position of a component within its container. There is no process among the layout managers to capture the way a component changes its size or position when the container is resized. Furthermore, existing layout managers have complex internal state data that attaches to a GUI that must be saved to persistent storage and restored. For example, with FlowLayout it may be the alignment and gap sizes, or the rows, columns, and gap sizes for GridLayout, or a host of variables for GridBagLayout. In addition, layout specific constraint objects may also need to accompany each component in the GUI.
Another drawback of existing layout managers, notably in the more powerful ones, is the lack of a constraintless add function, which forces designers to layout components using programming code, rather than using a graphical layout tool. FlowLayout and BoxLayout allow a constraintless add function, but FlowLayout does not align in the vertical direction and BoxLayout forces everything to be the same size.
Therefore, it would be desirable to have a layout manager that is easy and intuitive to use without sacrificing flexibility, robustness, and power. It should allow a user to position and size components, using a drag and drop process, as desired, without limitations and constraints that prevent designing an optimal GUI with reduced time and effort from the designer. It would also be desirable to have a layout manager that is stateless such that state data is contained in the individual components and one that can optionally conform to Java(trademark) look and feel guidelines.
To achieve the foregoing invention, methods, apparatus, and computer-readable media are disclosed for managing the construction or creation of a user interface. In one aspect of the invention, a method of managing the creation of a user interface involves deriving values for a set of internal client properties that attach to a new component. A component is brought into a container, or user interface area, from a component palette. Using the client properties, size values and position values are calculated for the component. The calculations are done using integer values only, thereby simplifying the calculation process. If there are existing components in the user interface, values for the other components are recalculated using the same set of client properties (with different values) and the same set of size and position formulas. This way any resizing and repositioning of components are done automatically. Once the client properties are derived, they are stored with the component. A user interface having multiple components can then be reconstructed from state data in the components.
In another aspect of the present invention, a method of representing a component in a user interface is describe. The component has a position and size in the user interface, which, in turn, has multiple columns that have a particular column type. In one embodiment, struts and springs define column and row types. A fixed strut or spring allows a developer how wide or tall a component should be. A spring allows for the area of a component to be dynamic. A set of internal client properties is associated with the component when the component is first brought into the user interface. Each property value can be represented as an integer. The particular column type, as well as a row type for the multiple rows in the user interface, can be inferred form the set of client properties. The client property values are also used to derive position values and size values for the component. The size and position values are also integer values and can be derived easily from the client property values. The component is encapsulated with the set of properties and the size and position values before being stored.